Communications networks continue to have a growing role in today's world. FIG. 1 is a conceptual diagram illustrating an example of a communications network 100. As used herein, a “communications network” or a “network,” for example, network 100, is group of two or more devices (i.e., network elements), for example, network devices 102, 104 and 106, interconnected by one or more segments of transmission media on which communications may be exchanged between the devices. Each segment may be any of a plurality of types of transmission media, including one or more electrical or optical wires or cables made of metal and/or optical fiber, air (e.g., using wireless transmission over carrier waves) or any combination of these transmission media. As used herein, “plurality” means two or more.
As networks become more complex and continue to include more network devices, the importance of efficiently managing these devices has grown. As used herein, a “network device” is a device configured as part of a network. Such network devices may be and/or include any of a variety of types of devices, including, but not limited to, switching devices, workstations, personal computers, terminals, laptop computers, end stations, servers, gateways, registers, directories, databases, printers, fax machines, telephones, transmitters, receivers, repeaters, and any combinations thereof.
Managing network devices is referred to herein as “device management,” and includes, inter alia, configuring a plurality of network devices, where one or more these network devices are typically configured remotely (i.e., from another network device residing at a different location on the network) by exchanging messages (e.g., packets) between network devices over network media.
To facilitate configuring large numbers of network devices, object types often are defined to represent aspects of network devices, for example, status, location (e.g., Internet Protocol (IP) address and/or Media Access Control (MAC) address), port characteristics, device description, other aspects, permissible states of any aspects, or any combination thereof.
Objects
The term “object” is often used inconsistently in the field of communications networks, including the field of device management. The meaning of the term “object” and related terms as used herein will now be defined.
As used herein, an “object” is an abstraction representing a specific occurrence (i.e., an instance) of an object type.
As used herein, an “object type” is an abstraction representing a type of thing, for example, a type of thing associated with a network device, for example, the network device itself, a Virtual Local Area Network (VLAN), an interface of the network device, any aspects thereof, other aspects, or any combination thereof.
For example, an object type may define an interface of a network device, where a specific object of the object type may be instantiated for a particular interface of a particular network device.
An object type may include one or more other object types and may be included within one or more other object types. Accordingly, an object type may define interrelationships between object types and may define an organizational structure of object types.
Some object types, referred to herein as “non-indexed” object types (and often referred to as zero-instanced object types), are configured such that only a single object of the object type can occur (i.e., can be instantiated) per network device. For example, an object type may define an operating system for a network device, for which only a single object occurs for each network device.
Other object types, referred to herein as “indexed” object types are configured such that one or more objects of the object type may occur for a single network device. In such case, where one or more objects of a same object type may occur for a single device, each object may be referred to as an “occurrence” (i.e., an instance) of the object type, and each occurrence may be indexed by an indexing variable. For example, an object type defining an interface of a network device may have one or more objects occur per network device, and each of these objects may be referred to as an occurrence of the object type, i.e., an occurrence of an interface. Further, the interface object type may be defined to include several other object types, and each such object type may occur one or more times on a network device, i.e., once for every occurrence of the interface object type.
Network Object Database
A plurality of objects may be grouped together to form a network object database. As used herein, a “network object database” is an organized collection of one or more network objects.
As used herein, a “network object” is an object representing a specific occurrence (i.e., an instance) of an network object type. A “network object type” is an object type representing a type of thing associated with a network device, for example, the network device itself, a Virtual Local Area Network (VLAN), an interface of the network device, any aspects thereof, other aspects, or any combination thereof.
An example of a network object database is a Management Information Base (MIB). A network object database may be any of a variety of types of databases, for example, an object-oriented database, a flat file database, a relational database, or combination thereof. Some network object databases organize network object types into object type groups and/or tables, where the database schema of such database may divide several logically-related object types into several tables and/or object type groups. For example, some MIBs include an interface group, a system group, and/or a VLAN group, etc. A device management application may be configured to understand such relationships, and a programmer or other person experienced in working with the database may know such relationships. Typically, however, a user (e.g., a network administrator) has limited knowledge or understanding of the relationships between such tables and table entries.
An indexed object type (e.g., an interface) of a network object database (e.g., a MIB) may include a table object type defining a table for the indexed object type. The table object type includes an object type that defines an indexing variable for the table and other object types that define columns for the table. The table object type may be defined such that each occurrence of the indexed object type is indexed by the indexing variable and may be considered an entry or row of the table. The column object types may be defined to occur once for each occurrence of the indexed object type, i.e., once for each entry or row of the table.
To facilitate the widespread use of network object databases to manage devices, several technologies, standards and protocols have been developed. Some of these standards have been developed to define a language for structuring management information, including the Structure of Management Information (SMI) promulgated by the Internet Engineering Task Force (IETF), including IETF Standard No. 16, which defines Version 1 of the SMI as documented in Request for Comments (RFCs) 1155 and 1212, and IETF Standard No. 58, which defines Version 2 of the SMI as documented in RFCs 2578, 2579 and 2580.
Other protocols have been developed to enable a user to manage objects and object types of a network object database (e.g., a MIB). Managing a database of network objects may include accessing (e.g., remotely) and manipulating (e.g., getting and setting) object types and occurrences thereof, including modifying the definition of an object type and/or changing a value defined for an object. An example of a protocol for managing a MIB is the Simple Network Management Protocol (SNMP) promulgated by the IETF. There are several different versions of SNMP, including SNMPv1 (version 1) as defined by IETF Standard No. 15 and documented in RFC 1157, SNMPv2c, which is not a standard, but is an experimental version of SNMP as documented in RFC 1901, and SNMPv3 defined by IETF Standard No. 62 and documented in RFCs 3410-3418, which are updated versions of RFCs 1905-1907 and 2570-2575.
Accordingly, a network object database, for example, a MIB, may be configured to conform with one or more of the SMI protocols and one or more of the SNMP protocols. A network object database also may include proprietary elements that do not conform with any standards or protocols.
Views
As used herein, a “view” of a network object database (e.g., MIB) is a visual representation of information derived from the network object database. The visually represented information may be any information derived from the network object database, for example, the values of one or more objects on a network device. A view typically represents a subset of the information available from a network object database, and typically is used by a user to determine the state of one or more network objects on one or more devices. As used herein, a “view definition” is a set of computer-readable signals that defines a view. As used herein, a “set” of items may include one or more of such items. A view definition includes a definition of the information to be represented by the view.
A network object database may be considered a layer of abstraction for aspects of a network device. Views of a network object database may be classified as abstracted or non-abstracted. As used herein, a “non-abstracted view” is a view of a network object database that provides no more abstraction (i.e., no additional layer of abstraction) for network objects beyond the layer of abstraction provided by the network object database itself. Thus, a non-abstracted view visually represents only information defined in the network object database.
Also, non-abstracted views are limited to arranging the display of information from the network object database as defined by the network object database itself. For example, such non-abstracted view delimits objects only in accordance with the delimitations defined by the network object database. Further, existing non-abstracted view definitions do not combine or collate object types of different groups or different tables of a network object database into an integrated arrangement, e.g., a table that includes object types from both groups or tables.
Typically, relatively simple interpretive (as opposed to compiled) programming language such as a scripting language (e.g., Practical Extraction and Reporting Language (PERL)) are used to write instructions in code (e.g., a script) to retrieve network objects to produce a non-abstracted view. Using a programming interface (e.g., an editor), a programmer may write a script that defines requests for objects defined for one or more network devices, and then execute the script.
As used herein, a “programming interface” is a set of one or more applications, or parts thereof, that enable a programmer to create and modify an application. A programming interface may be configured to use one or more Application Programming Interfaces (APIs), The programmer must know how to write programming code using the programming interface and/or understand the functionality defined by blocks of code (e.g., building blocks of an API) and how to properly combine them.
The result of executing a script on a network object database typically is a raw dump of information including values of objects of the requested object types. The information typically is visually arranged according to the arrangement of the objects within the network object database, which is defined by the object types therein. The information is typically is arranged as a string of text with delimiters (e.g., spaces, line spaces, carriage returns, commas, semicolons) separating objects.
Thus, such relatively simple programming languages do not enable a programmer to define an abstract view of a network object database, including configuring an arrangement of network objects different than the arrangement defined by the network object database, and/or defining a graphical arrangement of such network objects, for example, a table. Thus, the information displayed and the arrangement of information displayed is limited to the information and arrangement defined by the network object database.
As a result, such non-abstracted views may have little meaning to the user (relative to the meaning provided by an abstract view definition), and the logical relationships between pieces of information visually represented in the view may be difficult for the user to understand or may not be understood by the user at all.
Further, the scripts written by such relatively simple programming languages do not provide a user interface that enables a user to create and modify a view definition.
As used herein, a “user interface” is an application or part of an application (i.e., a set of computer-readable instructions) that enables a user to interface with an application during execution of the application. A user interface may include code defining how an application outputs information to a user during execution of the application, for example, visually through a computer screen or other means, audibly through a speaker of other means, and manually through a game controller or other means. Such user interface also may include code defining how a user may input information during execution of the application, for example, audibly using a microphone or manually using a keyboard, mouse, game controller, track ball, touch screen or other means.
Some known applications, for example, NetSight Element Manager, version 3.0.0, available from Enterasys Networks, Inc. of Rochester, New Hampshire, can provide abstracted views of a network object database. Typically, programmers can create and modify abstract view definitions for such applications using a programming interface.
As used herein, an “abstracted view” is a view of a network object database that provides a layer of abstraction of network objects beyond the layer of abstraction provided by the network object database itself. A definition of an abstracted view (i.e., view definition) may specify information beyond the information defined in the network object database, for example, different names for the objects than the names provided by the network object database. Further, the view definition for an abstracted view may define a visual arrangement (e.g., a table) of the information to be represented that is different than the visual arrangement defined by the network object database. For example, an abstracted view may define a table that includes object types that belong to different object type groups or different tables of a network object database.
Similar to the limitations described above with respect to scripts, applications for which programmers can define abstracted views do not provide a user interface that enables a user to create and modify a view definition for a network object database.
In contrast, the static views provided by such applications can only be created and modified by programmers, for example, using a programming interface. As used herein, a “static view definition” is a view definition of a network object database that is not capable of being created and/or modified without programming intervention to create or change the programming code in which the view definition is written (e.g., using a programming interface).
Static view definitions restrict users to view definitions configured by a programmer, for example, when a viewing application is installed. Further, the view definition may be restricted to those object types that were known when the viewing application was installed. Accordingly, to modify a view definition, including possibly adding new object types to the view definition, or to create a new view definition, the code defining the viewing application must be modified. Such modification adds additional time and, consequently, cost to managing network devices.
Another problem with known applications that provide abstracted views of a network object database is that the view definitions of such views are typically inextricable from the viewing application and, therefore, are not portable. In other words, a user using a first network device cannot separate a view definition from the viewing application and transport the view definition to another network device where the view defined by the view definition can be reproduced using a suitable viewing application. Transporting a view definition may include transmitting the view to another device over network media (e.g., by attaching to an email), or saving a copy of the view to a portable recording medium such as a memory stick, CD ROM or floppy disk and physically transporting the recording medium to another network device.